Skip to content

Conversation

original-brownbear
Copy link
Contributor

@original-brownbear original-brownbear commented Feb 6, 2025

Shortest version I could think of for this from where we are now.

This change moves the query phase a single roundtrip per node just like can_match or field_caps work already.
A a result of executing multiple shard queries from a single request we can also partially reduce each node's query results on the data node side before responding to the coordinating node.

As a result this change significantly reduces the impact of network latencies on the end-to-end query performance, reduces the amount of work done (memory and cpu) on the coordinating node and the network traffic by factors of up to the number of shards per data node!

Benchmarking shows up to orders of magnitude improvements in heap and network traffic dimensions in querying across a larger number of shards.

Shortest version I could think of. Still WIP, have to make some test adjustments and polish rough edges,
but it shouldn't get longer than this.
@original-brownbear
Copy link
Contributor Author

trivial dependency: #121887

@original-brownbear
Copy link
Contributor Author

Another trivial dependency #121922 to avoid some duplication here and remove existing dead code.

original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Feb 10, 2025
An easy change we can split out of elastic#121885 to make that shorter.
@original-brownbear
Copy link
Contributor Author

Alrighty, flag is in place, serverless setting reference is removed :)

Thanks Luca + Jim! I'll open a back port PR to 8.19 after some benchmarking! :)

@original-brownbear original-brownbear merged commit fd2cc97 into elastic:main Mar 29, 2025
16 of 17 checks passed
@original-brownbear original-brownbear deleted the batched-exec-short branch March 29, 2025 15:53
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Apr 4, 2025
elasticsearchmachine pushed a commit that referenced this pull request Apr 4, 2025
…22188) (#126293)

An easy change we can split out of #121885 to make that shorter.
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Apr 9, 2025
…121885)

This change moves the query phase a single roundtrip per node just like can_match or field_caps work already.
A a result of executing multiple shard queries from a single request we can also partially reduce each node's query results on the data node side before responding to the coordinating node.

As a result this change significantly reduces the impact of network latencies on the end-to-end query performance, reduces the amount of work done (memory and cpu) on the coordinating node and the network traffic by factors of up to the number of shards per data node!

Benchmarking shows up to orders of magnitude improvements in heap and network traffic dimensions in querying across a larger number of shards.
original-brownbear added a commit that referenced this pull request Apr 10, 2025
…#126563)

* Introduce batched query execution and data-node side reduce (#121885)

This change moves the query phase a single roundtrip per node just like can_match or field_caps work already.
A a result of executing multiple shard queries from a single request we can also partially reduce each node's query results on the data node side before responding to the coordinating node.

As a result this change significantly reduces the impact of network latencies on the end-to-end query performance, reduces the amount of work done (memory and cpu) on the coordinating node and the network traffic by factors of up to the number of shards per data node!

Benchmarking shows up to orders of magnitude improvements in heap and network traffic dimensions in querying across a larger number of shards.

* Filter out empty top docs results before merging (#126385)

`Lucene.EMPTY_TOP_DOCS` to identify empty to docs results. These were previously
null results, but did not need to be send over transport as incremental reduction
was performed only on the data node.

Now it can happen that the coord node received a merge result with empty top docs,
which has nothing interesting for merging, but that can lead to an exception because
the type of the empty array does not match the type of other shards results, for
instance if the query was sorted by field. To resolve this, we filter out empty
top docs results before merging.

Closes #126118

---------

Co-authored-by: Luca Cavanna <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>enhancement release highlight :Search Foundations/Search Catch all for Search Foundations Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v9.1.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants